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ARGUMENT 

Rejection of Claims 1 and 8 under 35 U.S.C. 112, second paragraph 



In the Final Office Action mailed on November 26, 2010, Claims 1 and 8 have been 
rejected under 35 U.S.C. §112, second paragraph. 

With regard to Claims 1 and 8, the Examiner, on page 5 of the Examiner's Answer mailed 
on August 4, 201 1 (hereinafter "the Examiner's Answer"), reiterates the previous grounds of 
rejection. The Appellant's position regarding the Examiner's 35 U.S.C. §112 rejection is 
maintained with regard to the arguments presented in the Appeal Brief submitted on June 30, 
2011. 

In addition, on page 16 of the Examiner's Answer, the Examiner states that "the instant 
application is devoid of the term 'distinct '...the specification does not provide one of ordinary 
skill in the art with the means for distinguishing what is 'distinct' from what is not." 

The Appellant respectfully disagrees. "[T]he ordinary and customary meaning of a claim 
term is the meaning that the term would have to a person of ordinary skill in the art in question at 
the time of the invention, i.e., as of the effective filing date of the patent application." (Phillips v. 
AWH Corp., 75 USPQ2d 1321, 1326, (Fed. Cir., 2005.) "If more than one extrinsic definition is 
consistent with the use of the words in the intrinsic record, the claim terms may be construed to 
encompass all consistent meanings. (MPEP 2111.1 III) Where a term is not expressly defined in 
the Specification, the term should be given the broadest reasonable interpretation that the ordinary 
meaning allows. ("Where no explicit definition for the term 'electronic multi-function card' was 
given in the specification, this term should be given its ordinary meaning and broadest reasonable 
interpretation; the term should not be limited to the industry standard definition of credit card 
where there is no suggestion that this definition applies to the electronic multi-function card as 
claimed, and should not be limited to preferred embodiments in the specification," E-Pass 
Technologies, Inc. v. 3Com Corporation, 67 USPQ2d 1947, 1949 (Fed. Cir. 2003)). The term 
"distinct" is a common term, and, within the context of the claim language as drafted, one of 
ordinary skill in the art would understand that distinct means separate. Therefore the element 
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"said provider offering being distinct from a resource catalog" does comply with the written 
description requirement because one of ordinary skill in the art would understand that the 
inventors, at the time the Application was filed, had possession of the claimed invention. 

Therefore, for at least these reasons, the element "said provider offering being distinct 
from a resource catalog" clearly complies with the written description requirement. The 
Appellant respectfully requests reconsideration and withdrawal of the rejection of Claim 1 . 

With regard to Claim 8, on page 16 of the Examiner's Answer, the Examiner states that 
"the instant application is devoid of the term 'distinct '...the specification does not provide one of 
ordinary skill in the art with the means for distinguishing what is 'distinct' from what is not." 

The Appellant respectfully disagrees. "[T]he ordinary and customary meaning of a claim 
term is the meaning that the term would have to a person of ordinary skill in the art in question at 
the time of the invention, i.e., as of the effective filing date of the patent application." (Phillips v. 
AWH Corp., 75 USPQ2d 1321, 1326, (Fed. Cir., 2005.) "If more than one extrinsic definition is 
consistent with the use of the words in the intrinsic record, the claim terms may be construed to 
encompass all consistent meanings. (MPEP 2111.1 III) Where a term is not expressly defined in 
the Specification, the term should be given the broadest reasonable interpretation that the ordinary 
meaning allows. ("Where no explicit definition for the term 'electronic multi-function card' was 
given in the specification, this term should be given its ordinary meaning and broadest reasonable 
interpretation; the term should not be limited to the industry standard definition of credit card 
where there is no suggestion that this definition applies to the electronic multi-function card as 
claimed, and should not be limited to preferred embodiments in the specification," E-Pass 
Technologies, Inc. v. 3Com Corporation, 67 USPQ2d 1947, 1949 (Fed. Cir. 2003)). The term 
"distinct" is a common term, and, within the context of the claim language as drafted, one of 
ordinary skill in the art would understand that distinct means separate. Therefore the element 
"said provider offering being distinct from a resource catalog" does comply with the written 
description requirement because one of ordinary skill in the art would understand that the 
inventors, at the time the Application was filed, had possession of the claimed invention. 

Therefore, for at least these reasons, the element "said provider offering being distinct 
from a resource catalog" clearly complies with the written description requirement. The 
Appellant respectfully requests reconsideration and withdrawal of the rejection of Claim 1 . 
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Rejection of Claims 1-15 under 35 U.S.C. 103(a) 

Claims 1-15 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Publication No. 2002/0107761 to Kark, et al. (hereinafter "Kark") in view of U.S. Publication 
No. 2002/0059090 to Yanagimachi (hereinafter "Yanagimachi"). 

With regard to Claims 1-15, the Examiner, on pages 5-15 of the Examiner's Answer, 
reiterates the previous grounds of rejection. The Appellant's position regarding the Examiner's 
35 U.S.C. § 103(a) rejection is maintained with regard to the arguments presented in the Appeal 
Brief submitted on June 30, 201 1 . 

In addition, with regard to Claim 1, the Examiner states, on page 17 of the Examiner's 
Answer, that Kark teaches "said provider offering being distinct from a resource catalog." 
Specifically, the Examiner states essentially, that the various filtered views of a catalog, as 
disclosed in Kark, teaches "said provider offering being distinct from a resource catalog," as 
recited inter alia in Claim 1 . The Appellant respectfully disagrees. Kark discloses a higher layer 
catalog comprising catalog information. (Kark, Para. [0041]) Kark further discloses that different 
users of the catalog may be able to view filtered versions of that catalog information. (Kark, Para. 
[0052].) Therefore, Kark discloses a catalog that includes provider offers, in combination with 
the ability to provide filtered views of the catalog information. ("Further aspects of the catalog 
systems and methods of the present invention enable filtering of presentation of a catalog 
information based upon factors such as the particular portal used to enter the catalog or based 
upon other criteria of the viewer of the catalog," Kark, Para. [0052] , emphasis added.) This does 
not teach or suggest "said provider offering being distinct from a resource catalog," as recited 
inter alia in Claim 1 . Furthermore, the Examiner states that Kark teaches the functionality to 
"generat[e] and maintain product catalogs. . .selectively copying portions of the industry catalogs 
to a plurality of channel partner catalogs." Kark, however, discloses that a subset of catalog 
databases may be created from one catalog database in order to provide a subset of the larger 
database, ("a new channel partner catalog database may be created that selects only particular 
goods or services from manufacturers and/or selects only particular manufacturers," Kark, Para. 
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[0106], emphasis added.) The Examiner states that the way Kark presents the catalog offerings 
allows for "Each end user's catalog view [to be] unique or distinct based on their filtering 
settings." (the Examiner's Answer, pg. 17.) Kark therefore, does not teach or suggest "said 
provider offering being distinct from a resource catalog ," but discloses instead that a new catalog 
view , that itself includes product offerings, and can be made from another, larger, product catalog, 
that itself includes a full set of product offerings. (Kark, Para. [0106.].) 

In addition, with regard to Claim 1, the Examiner alleges that Kark teaches "using said 
provider offering by the transformation component as a root node of a customer specific service 
environment topology tree to be generated." Specifically, the Examiner states that "the channel 
partner catalog [of Kark] is interpreted to be the root node, and the particular market catalogs 
derived are interpreted to be the claimed 'customer specific service environment topology tree'." 
(the Examiner's Answer, pg. 20.) Kark discloses that custom catalogs may be created be 
extracting information (i.e. filtering) from a corresponding channel partner storefront catalog, ("a 
method of the present invention that applies the STOPLIST tables of the database to filter out 
particular products from the catalog based upon external parameters," Kark, Paras. [0075], and 
[0121], emphasis added.) The Examiner points to FIG. 4 of Kark in support of this 
interpretation. Although FIG. 4 depicts several layers of catalog information, there is nothing in 
Kark that teaches or suggests that FIG. 4 teaches "a customer specific service environment 
topology tree to be generated," as recited inter alia in Claim 1 . Rather, Kark discloses that FIG. 
4 is a representation of the structure of the various catalogs and catalog views. ("FIG. 4 is a 
block diagram of a hierarchical catalog structure of the present invention reflecting the structure 
of e-commerce channel marketing," Kark, Para. [0075], emphasis added.) Kark, in fact, is 
devoid of teaching or suggesting a tree of any kind. Assuming, arguendo, that FIG. 4 does depict 
"a customer specific service environment topology tree to be generated," which it does not, and 
applying the Examiner's interpretation that FIG. 4 depicts "a tree" FIG. 4 depicts no root node 
per se, but a plurality of manufacture catalogs feeding an industry master catalog which feeds the 
rest of the hierarchy. (Kark, FIG. 4.) Therefore, for at least these reasons, Kark does not teach 
or suggest "using said provider offering by the transformation component as a root node of a 
customer specific service environment topology tree to be generated," as recited inter alia in 
Claim 1. 
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In addition, with regard to Claim 1, the Examiner alleges that Kark teaches "adding 
identified resource types as nodes in said topology tree which are mapping with said provider 
offering." The Examiner alleges that the "LINK table" of Kark "creates linkages and ties among 
products." (The Examiner's Answer, pg. 20.) The Examiner alleges that the linking in Kark 
teaches "mapping." (The Examiner's Answer, pg. 20.) As stated above, Kark is devoid of 
teaching a "topology tree" or trees of any kind, therefore Kark does not teach or suggest "adding 
identified resource types as nodes in said topology tree which are mapping with said provider 
offering," as recited inter alia in Claim 1 . Furthermore, assuming arguendo that Kark does 
disclose a "topology tree," which it does not, Kark discloses that the link table links related 
products to one another, and does not teach or suggest "adding identified resource types as nodes 
in said topology tree which are mapping with said provider offering." ("The LINK table 506 is 
used to define marketing linkages and ties among products . For example, it may be useful in a 
marketing catalog to link an electronic toy in the catalog with batteries because users of the 
catalog who purchase such a toy are likely to purchase the required batteries," Kark, Para. 
[0097], emphasis added.) In an alternate interpretation of Claim 1 , the Examiner alleges that 
Kark additionally teaches linking products to catalogs, however, this teaching in Kark does not 
teach or suggest "adding identified resource types as nodes in said topology tree which are 
mapping with said provider offering," as recited inter alia in Claim 1 , but merely discloses linking 
products to catalogs. ("The PRODUCT ID is a unique value used as a key for the table and the 
CATALOGID links each record to the particular catalog in which it is included," Kark, Para. 
[0085], emphasis added.) 

In addition, with regard to Claim 1, the Examiner alleges that Kark teaches "adding child 
nodes to said identified nodes when said identified resource types, which are aggregated resource 
types, map into a set of lower level resource types which are child resources." As stated above, 
Kark does not teach or suggest "adding identified resource types as nodes in said topology tree," 
and therefore cannot teach or suggest "adding child nodes to said identified nodes when said 
identified resource types. . .map into a set of lower level resource types which are child resources," 
as recited inter alia in Claim 1 . The Examiner alleges that products in the aggregate main catalog 
are linked to other sub-products and/or sub-components via a LINKFROM field. (Examiner's 
Answer, pg. 21.) Assuming, arguendo, that the Examiner's interpretation of Kark is correct, this 
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linking of products to their sub-products and/or sub-components still does not teach or suggest 
"adding child nodes to said identified nodes when said identified resource types, which are 
aggregated resource types, map into a set of lower level resource types which are child 
resources," as recited inter alia in Claim 1 . Kark discloses that this link between products and 
sub-products and/or components is used to allow "recursive definitions" of products. ("The 
LINKFROM field in this table indicates another product, if any, from which this record represents 
a sub-product or sub-component. Such linking of products permits recursive definition of the 
products to provide a richer definition of products and related sub-products. For example, 
"TABLE SAW" may be the name of a product and "SAW BLADE" may be the name of a related 
sub-product.," Kark, Para. [0085], emphasis added.) One of ordinary skill in the art would 
understand that the LINKFROM field of Kark is used to link together a group of products that 
roll up to a single parent product and therefore docs not teach or suggest "mapping said 
description of said provider offering with said resource type information . . .comprising the steps 
of: . . . adding child nodes to said identified nodes when said identified resource types , which are 
aggregated resource types, map into a set of lower level resource types which arc child 
resources " as recited inter alia in Claim 1 . ('The LINKFROM field of a highest level product 
(one which is not a sub-product of another product) indicates the CATEGORYID value of the 
category, if any, to which it is linked, or, if not included in a category, the LINKFROM field for 
such a product indicates a NULL or other invalid value to so indicate a top level product ," Kark, 
Para. [0085], emphasis added.) 

In addition, with regard to Claim 1, the Examiner alleges that Kark teaches "compiling 
said sequenced management actions into a machine readable form executable by said resource 
management system." The Examiner alleges that Kark teaches "the process may also be 
performed automatically using time event processing and script controls." The Examiner alleges 
that, because Kark discloses scripting, and that scripting maybe considered computer executable 
programming, Kark by extension teaches "compiling said sequenced management actions into a 
machine readable form executable by said resource management system," as recited inter alia in 
Claim 1 . ("scripting is an old and well known synonym for computer executable programming. 
The scripting of Kakr inherently is contained on a computer readable medium. Therefore the 
teachings of Kark would have rendered the claimed limitations obvious to one of ordinary skill in 
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the art at the time the invention was made," the Examiner's Answer, pg. 22.) The Examiner 
additionally appears to interpret the aggregation of catalog data into a single master catalog as 
"compiling." The Examiner therefore apparently concludes, that because Kark allegedly teaches 
that the aggregation of a master catalog can be performed using a script, that Kark must teach or 
suggest "compiling said sequenced management actions into a machine readable form executable 
by said resource management system," as recited inter alia in Claim 1 . The Appellant 
respectfully disagrees. Kark discloses that manual process may be automated using scripting, 
however, Kark does not disclose "compiling said sequenced management actions into a machine 
readable form executable by said resource management system," as recited inter alia in Claim 1 . 
Claim 1 recites inter alia "providing access to a resource management action catalog containing 
resource management actions each describing how to manage a single resource type by a resource 
control system. . . extracting from said resource management action catalog all resource 
management actions of said resource types identified in said customer specific service 
environment resource topology tree; sequencing said extracted resource management actions 
according to requirements of said defined customer specific service environment; and compiling 
said sequenced management actions into a machine readable form executable by said resource 
management system ." The scripting of Kark, therefore, does not teach or suggest "compiling said 
sequenced management actions into a machine readable form executable by said resource 
management system," but discloses a way to automate catalog aggregation, ("an integrator or 
integration means that integrates updated information from a parent catalog into a child 
catalog . . .This particular integration is performed under the manual control of a user. As noted 
above, the process may also be performed automatically using timed event processing and 
scripting controls as well-known in present computing systems," Kakr, Para. [0113], emphasis 
added.) 

Yanagimachi does not correct the deficiencies identified with Kark. Therefore, for at least 
these reasons, Claim 1 is allowable over Kark in view of Yanagimachi. The Appellant respectfully 
requests reconsideration and withdrawal of the rejection of Claim 1 . 

Claims 2-7 depend from Claim 1 and are believed to be allowable for at least the reason 
that they depend from an allowable base claim. 
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With regard to Claim 7, the Examiner alleges that Kark teaches "said reference 
information includes a URL pointing to a Web Service with the corresponding Web Service 
description for execution of said resource management actions." The Examiner states because 
Kark discloses an Internet portal, and because Kark discloses that the catalogs are maintained on 
a standard XML format, that, Kark discloses "said reference information includes a URL pointing 
to a Web Service with the corresponding Web Service description for execution of said resource 
management actions," as recited inter alia in Claim 7. The Examiner further states that "By its 
very definitions an internet portal is equivalent [to] the claimed limitation." (The Examiner's 
Answer, pg. 23.) Kark, however, provides a definition of a portal as a front-end Internet site used 
to attract customers, which, counter to the Examiner's allegation, does not teach or suggest "said 
reference information includes a URL pointing to a Web Service with the corresponding Web 
Service description for execution of said resource management actions ," as recited inter alia in 
Claim 7. ("As used herein a "portal" is an Internet site designed to attract users based upon 
particular content available through that site. However in this case, there is no assistance or help 
for each reseller. . .his portal model is shown in FIG. 2 wherein a portal site 200 provides a 'front- 
end' interface to present the catalogs," Kark, Paras. [00 19]- [0020], emphasis added.) 

The Examiner further states that it is old and very well known that a portal is a website, 
and that a website is a web service, ("it is old and very well known in the art that a portal is a 
website ( web service ) that presents information from diverse sources in a unified manner," the 
Examiner's Answer, pg. 23, emphasis added.) The Examiner, therefore alleges that a portal is a 
website and that all websites are web services, (the Examiner's Answer, pg. 23.) Those of 
ordinary skill in the art would understand that a "web service" is a term of art used to describe 
very specific XML based service supported by a Web Service Definition Language (WSDL), and 
not a "website" as alleged by the Examiner. ("For example the resource management actions 
action may be described by a URL pointing to a web service with the corresponding web service 
description in form of a WSDL , Specification, Pg. 15, lines 12-15, emphasis added.) 
Furthermore, assuming, arguendo, that the Examiner's interpretation of a website as a web 
service is correct, which it is not, Kark discloses that a portal is an Internet website designed to 
attract users, and that the portals provide a "front-end interface" to the catalog data. ("As used 
herein a "portal" is an Internet site designed to attract users based upon particular content 
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available through that site. However in this case, there is no assistance or help for each 
reseller. . .his portal model is shown in FIG. 2 wherein a portal site 200 provides a 'front-end' 
interface to present the catalogs," Kark, Paras. [0019]-[0020], emphasis added.) Kark further 
discloses that master catalog data is aggregated from several manufacturer catalogs, and that this 
process is facilitated by using XML. ("Manufacturer catalog information is preferably fed to the 
master catalog of the present invention in industry-standard XML formats," Kark, Para. [0038].) 
Kark, however, is devoid of teaching or suggesting that this XML, which is used in the 
aggregation process, is also used at the "portal" as alleged by the Examiner, and therefore does 
not teach or suggest "said reference information includes a URL pointing to a Web Service with 
the corresponding Web Service description for execution of said resource management actions 

Furthermore, Kark is devoid of teaching or suggesting "said reference information 
includes a URL pointing to a Web Service with the corresponding Web Service description for 
execution of said resource management actions," as recited inter alia in Claim 7. 

Yanagimachi does not correct the deficiencies identified with Kark. Therefore, for at least 
these reasons, Claim 7 is allowable over Kark in view of Yanagimachi. The Appellant respectfully 
requests reconsideration and withdrawal of the rejection of Claim 7. 

In addition, with regard to Claim 8, the Examiner states, on page 17 of the Examiner's 
Answer, that Kark teaches "said provider offering being distinct from a resource catalog." 
Specifically, the Examiner states essentially, that the various filtered views of a catalog, as 
disclosed in Kark, teaches "said provider offering being distinct from a resource catalog," as 
recited inter alia in Claim 8. The Appellant respectfully disagrees. Kark discloses a higher layer 
catalog comprising catalog information. (Kark, Para. [0041]) Kark further discloses that different 
users of the catalog may be able to view filtered versions of that catalog information. (Kark, Para. 
[0052].) Therefore, Kark discloses a catalog that includes provider offers, in combination with 
the ability to provide filtered views of the catalog information. ("Further aspects of the catalog 
systems and methods of the present invention enable filtering of presentation of a catalog 
information based upon factors such as the particular portal used to enter the catalog or based 
upon other criteria of the viewer of the catalog," Kark, Para. [0052] , emphasis added.) This does 
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not teach or suggest "said provider offering being distinct from a resource catalog," as recited 
inter alia in Claim 8. Furthermore, the Examiner states that Kark teaches the functionality to 
"generat[e] and maintain product catalogs. . .selectively copying portions of the industry catalogs 
to a plurality of channel partner catalogs." Kark, however, discloses that a subset of catalog 
databases may be created from one catalog database in order to provide a subset of the larger 
database, ("a new channel partner catalog database may be created that selects only particular 
goods or services from manufacturers and/or selects only particular manufacturers," Kark, Para. 
[0106], emphasis added.) The Examiner states that the way Kark presents the catalog offerings 
allows for "Each end user's catalog view [to be] unique or distinct based on their filtering 
settings." (the Examiner's Answer, pg. 17.) Kark therefore, does not teach or suggest "said 
provider offering being distinct from a resource catalog ," but discloses instead that a new catalog 
view , that itself includes product offerings, and can be made from another, larger, product catalog, 
that itself includes a full set of product offerings. (Kark, Para. [0106.].) 

In addition, with regard to Claim 8, the Examiner alleges that Kark teaches "using said 
provider offering as root node of a customer specific service environment topology tree to be 
generated." Specifically, the Examiner states that "the channel partner catalog [of Kark] is 
interpreted to be the root node, and the particular market catalogs derived are interpreted to be 
the claimed 'customer specific service environment topology tree'." (the Examiner's Answer, pg. 
20.) Kark discloses that custom catalogs maybe created be extracting information (i.e. filtering) 
from a corresponding channel partner storefront catalog, ("a method of the present invention that 
applies the STOPLIST tables of the database to filter out particular products from the catalog 
based upon external parameters," Kark, Paras. [0075], and [0121], emphasis added.) The 
Examiner points to FIG. 4 of Kark in support of this interpretation. Although FIG. 4 depicts 
several layers of catalog information, there is nothing in Kark that teaches or suggests that FIG. 4 
teaches "a customer specific service environment topology tree to be generated," as recited inter 
alia in Claim 8. Rather, Kark discloses that FIG. 4 is a representation of the structure of the 
various catalogs and catalog views. ("FIG. 4 is a block diagram of a hierarchical catalog structure 
of the present invention reflecting the structure of e-commerce channel marketing," Kark, Para. 
[0075], emphasis added.) Kark, in fact, is devoid of teaching or suggesting a tree of any kind. 
Assuming, arguendo, that FIG. 4 does depict "a customer specific service environment topology 
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tree to be generated," which it does not, and applying the Examiner's interpretation that FIG. 4 
depicts "a tree" FIG. 4 depicts no root node per se, but a plurality of manufacture catalogs 
feeding an industry master catalog which feeds the rest of the hierarchy. (Kark, FIG. 4.) 
Therefore, for at least these reasons, Kark does not teach or suggest "using said provider offering 
as root node of a customer specific service environment topology tree to be generated," as recited 
inter alia in Claim 8. 

In addition, with regard to Claim 8, the Examiner alleges that Kark teaches "adding 
identified resource types as nodes in said topology tree which are mapping with said provider 
offering." The Examiner alleges that the "LINK table" of Kark "creates linkages and ties among 
products." (The Examiner's Answer, pg. 20.) The Examiner alleges that the linking in Kark 
teaches "mapping." (The Examiner's Answer, pg. 20.) As stated above, Kark is devoid of 
teaching a "topology tree" or trees of any kind, therefore Kark does not teach or suggest "adding 
identified resource types as nodes in said topology tree which are mapping with said provider 
offering," as recited inter alia in Claim 8. Furthermore, assuming arguendo that Kark does 
disclose a "topology tree," which it does not, Kark discloses that the link table links related 
products to one another, and does not teach or suggest "adding identified resource types as nodes 
in said topology tree which are mapping with said provider offering." ("The LINK table 506 is 
used to define marketing linkages and ties among products . For example, it may be useful in a 
marketing catalog to link an electronic toy in the catalog with batteries because users of the 
catalog who purchase such a toy are likely to purchase the required batteries," Kark, Para. 
[0097], emphasis added.) In an alternate interpretation of Claim 8, the Examiner alleges that 
Kark additionally teaches linking products to catalogs, however, this teaching in Kark does not 
teach or suggest "adding identified resource types as nodes in said topology tree which are 
mapping with said provider offering," as recited inter alia in Claim 8, but merely discloses linking 
products to catalogs. ("The PRODUCTID is a unique value used as a key for the table and the 
CATALOGID links each record to the particular catalog in which it is included," Kark, Para. 
[0085], emphasis added.) 

In addition, with regard to Claim 8, the Examiner alleges that Kark teaches "adding child 
nodes to said identified nodes when said identified resource types which are aggregated resource 
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types, map into a set of lower level resource types which are child resources." As stated above, 
Kark does not teach or suggest "adding identified resource types as nodes in said topology tree," 
and therefore cannot teach or suggest "adding child nodes to said identified nodes when said 
identified resource types. . .map into a set of lower level resource types which are child resources," 
as recited inter alia in Claim 8. The Examiner alleges that products in the aggregate main catalog 
are linked to other sub-products and/or sub-components via a LINKFROM field. (Examiner's 
Answer, pg. 21.) Assuming, arguendo, that the Examiner's interpretation of Kark is correct, this 
linking of products to their sub-products and/or sub-components still does not teach or suggest 
"adding child nodes to said identified nodes when said identified resource types which are 
aggregated resource types, map into a set of lower level resource types which are child 
resources," as recited inter alia in Claim 8. Kark discloses that this link between products and 
sub-products and/or components is used to allow "recursive definitions" of products. ("The 
LINKFROM field in this table indicates another product, if any, from which this record represents 
a sub-product or sub-component. Such linking of products permits recursive definition of the 
products to provide a richer definition of products and related sub-products. For example, 
"TABLE SAW" may be the name of a product and "SAW BLADE" may be the name of a related 
sub-product.," Kark, Para. [0085], emphasis added.) One of ordinary skill in the art would 
understand that the LINKFROM field of Kark is used to link together a group of products that 
roll up to a single parent product and therefore does not teach or suggest "mapping said 
description of said provider offering with said resource type information . . .comprising the steps 
of: . . . adding child nodes to said identified nodes when said identified resource types , which are 
aggregated resource types, map into a set of lower level resource types which are child 
resources " as recited inter alia in Claim 8. ('The LINKFROM field of a highest level product 
(one which is not a sub-product of another product) indicates the CATEGORYID value of the 
category, if any, to which it is linked, or, if not included in a category, the LINKFROM field for 
such a product indicates a NULL or other invalid value to so indicate a top level product ," Kark, 
Para. [0085], emphasis added.) 

In addition, with regard to Claim 8, the Examiner alleges that Kark teaches "compiling 
said sequenced resource management actions into a machine readable form executable by said 
resource management system." The Examiner alleges that Kark teaches "the process may also be 
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performed automatically using time event processing and script controls." The Examiner alleges 
that, because Kark discloses scripting, and that scripting maybe considered computer executable 
programming, Kark by extension teaches "compiling said sequenced resource management actions 
into a machine readable form executable by said resource management system," as recited inter 
alia in Claim 8. ("scripting is an old and well known synonym for computer executable 
programming. The scripting of Kakr inherently is contained on a computer readable medium. 
Therefore the teachings of Kark would have rendered the claimed limitations obvious to one of 
ordinary skill in the art at the time the invention was made," the Examiner's Answer, pg. 22.) The 
Examiner additionally appears to interpret the aggregation of catalog data into a single master 
catalog as "compiling." The Examiner therefore apparently concludes, that because Kark 
allegedly teaches that the aggregation of a master catalog can be performed using a script, that 
Kark must teach or suggest "compiling said sequenced resource management actions into a 
machine readable form executable by said resource management system," as recited inter alia in 
Claim 8. The Appellant respectfully disagrees. Kark discloses that manual process may be 
automated using scripting, however, Kark does not disclose " compiling said sequenced resource 
management actions into a machine readable form executable by said resource management 
system," as recited inter alia in Claim 8. Claim 8 recites inter alia "providing access to a 
resource management action catalog containing resource management actions each describing 
how to manage a single resource type by a resource control system. . . extracting from said 
resource management action catalog all resource management actions of said resource types 
identified in said customer specific service environment resource topology tree; sequencing said 
extracted resource management actions according to requirements of said defined customer 
specific service environment; and compiling said sequenced resource management actions into a 
machine readable form executable by said resource management system .'" The scripting of Kark, 
therefore, does not teach or suggest "compiling said sequenced management actions into a 
machine readable form executable by said resource management system," but discloses a way to 
automate catalog aggregation, ("an integrator or integration means that integrates updated 
information from a parent catalog into a child catalog . . .This particular integration is performed 
under the manual control of a user. As noted above, the process may also be performed 
automatically using timed event processing and scripting controls as well-known in present 
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computing systems," Kakr, Para. [0113], emphasis added.) 

Yanagimachi does not correct the deficiencies identified with Kark. Therefore, for at least 
these reasons, Claim 8 is allowable over Kark in view of Yanagimachi. The Appellant respectfully 
requests reconsideration and withdrawal of the rejection of Claim 8. 

Claims 9-14 depend from Claim 8 and are believed to be allowable for at least the reason 
that they depend from an allowable base claim. 

In addition, with regard to Claim 15, the Examiner states, on page 17 of the Examiner's 
Answer, that Kark teaches "said provider offering being distinct from a resource catalog." 
Specifically, the Examiner states essentially, that the various filtered views of a catalog, as 
disclosed in Kark, teaches "said provider offering being distinct from a resource catalog," as 
recited inter alia in Claim 15. The Appellant respectfully disagrees. Kark discloses a higher layer 
catalog comprising catalog information. (Kark, Para. [0041]) Kark further discloses that different 
users of the catalog may be able to view filtered versions of that catalog information. (Kark, Para. 
[0052].) Therefore, Kark discloses a catalog that includes provider offers, in combination with 
the ability to provide filtered views of the catalog information. ("Further aspects of the catalog 
systems and methods of the present invention enable filtering of presentation of a catalog 
information based upon factors such as the particular portal used to enter the catalog or based 
upon other criteria of the viewer of the catalog," Kark, Para. [0052] , emphasis added.) This does 
not teach or suggest "said provider offering being distinct from a resource catalog," as recited 
inter alia in Claim 15. Furthermore, the Examiner states that Kark teaches the functionality to 
"generat[e] and maintain product catalogs. ..selectively copying portions of the industry catalogs 
to a plurality of channel partner catalogs." Kark, however, discloses that a subset of catalog 
databases may be created from one catalog database in order to provide a subset of the larger 
database, ("a new channel partner catalog database may be created that selects only particular 
goods or services from manufacturers and/or selects only particular manufacturers," Kark, Para. 
[0106], emphasis added.) The Examiner states that the way Kark presents the catalog offerings 
allows for "Each end user's catalog view [to be] unique or distinct based on their filtering 
settings." (the Examiner's Answer, pg. 17.) Kark therefore, does not teach or suggest "said 
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provider offering being distinct from a resource catalog ," but discloses instead that a new catalog 
view , that itself includes product offerings, and can be made from another, larger, product catalog, 
that itself includes a full set of product offerings. (Kark, Para. [0106.].) 

In addition, with regard to Claim 15, the Examiner alleges that Kark teaches "using said 
provider offering by the transformation component as a root node of a customer specific service 
environment topology tree to be generated." Specifically, the Examiner states that "the channel 
partner catalog [of Kark] is interpreted to be the root node, and the particular market catalogs 
derived are interpreted to be the claimed 'customer specific service environment topology tree'." 
(the Examiner's Answer, pg. 20.) Kark discloses that custom catalogs may be created be 
extracting information (i.e. filtering) from a corresponding channel partner storefront catalog, ("a 
method of the present invention that applies the STOPLIST tables of the database to filter out 
particular products from the catalog based upon external parameters," Kark, Paras. [0075], and 
[0121], emphasis added.) The Examiner points to FIG. 4 of Kark in support of this 
interpretation. Although FIG. 4 depicts several layers of catalog information, there is nothing in 
Kark that teaches or suggests that FIG. 4 teaches "a customer specific service environment 
topology tree to be generated," as recited inter alia in Claim 15. Rather, Kark discloses that FIG. 
4 is a representation of the structure of the various catalogs and catalog views. ("FIG. 4 is a 
block diagram of a hierarchical catalog structure of the present invention reflecting the structure 
of e-commerce channel marketing," Kark, Para. [0075], emphasis added.) Kark, in fact, is 
devoid of teaching or suggesting a tree of any kind. Assuming, arguendo, that FIG. 4 does depict 
"a customer specific service environment topology tree to be generated," which it does not, and 
applying the Examiner's interpretation that FIG. 4 depicts "a tree" FIG. 4 depicts no root node 
per se, but a plurality of manufacture catalogs feeding an industry master catalog which feeds the 
rest of the hierarchy. (Kark, FIG. 4.) Therefore, for at least these reasons, Kark does not teach 
or suggest "using said provider offering by the transformation component as a root node of a 
customer specific service environment topology tree to be generated," as recited inter alia in 
Claim 15. 

In addition, with regard to Claim 15, the Examiner alleges that Kark teaches "adding 
identified resource types as nodes in said topology tree which are mapping with said provider 
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offering." The Examiner alleges that the "LINK table" of Kark "creates linkages and ties among 
products." (The Examiner's Answer, pg. 20.) The Examiner alleges that the linking in Kark 
teaches "mapping." (The Examiner's Answer, pg. 20.) As stated above, Kark is devoid of 
teaching a "topology tree" or trees of any kind, therefore Kark does not teach or suggest "adding 
identified resource types as nodes in said topology tree which are mapping with said provider 
offering," as recited inter alia in Claim 15. Furthermore, assuming arguendo that Kark does 
disclose a "topology tree," which it does not, Kark discloses that the link table links related 
products to one another, and does not teach or suggest "adding identified resource types as nodes 
in said topology tree which are mapping with said provider offering." ("The LINK table 506 is 
used to define marketing linkages and ties among products . For example, it may be useful in a 
marketing catalog to link an electronic toy in the catalog with batteries because users of the 
catalog who purchase such a toy are likely to purchase the required batteries," Kark, Para. 
[0097], emphasis added. ) In an alternate interpretation of Claim 15, the Examiner alleges that 
Kark additionally teaches linking products to catalogs, however, this teaching in Kark does not 
teach or suggest "adding identified resource types as nodes in said topology tree which are 
mapping with said provider offering," as recited inter alia in Claim 15, but merely discloses 
linking products to catalogs. ("The PRODUCTID is a unique value used as a key for the table 
and the CATALOGID links each record to the particular catalog in which it is included," Kark, 
Para. [0085], emphasis added.) 

In addition, with regard to Claim 15, the Examiner alleges that Kark teaches "adding child 
nodes to said identified nodes when said identified resource types, which are aggregated resource 
types, map into a set of lower level resource types which are child resources." As stated above, 
Kark does not teach or suggest "adding identified resource types as nodes in said topology tree," 
and therefore cannot teach or suggest "adding child nodes to said identified nodes when said 
identified resource types. . .map into a set of lower level resource types which are child resources," 
as recited inter alia in Claim 15. The Examiner alleges that products in the aggregate main 
catalog are linked to other sub-products and/or sub-components via a LINKFROM field. 
(Examiner's Answer, pg. 21.) Assuming, arguendo, that the Examiner's interpretation of Kark is 
correct, this linking of products to their sub-products and/or sub-components still does not teach 
or suggest "adding child nodes to said identified nodes when said identified resource types, which 
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are aggregated resource types, map into a set of lower level resource types which are child 
resources," as recited inter alia in Claim 1 . Kark discloses that this link between products and 
sub-products and/or components is used to allow "recursive definitions" of products. ("The 
LINKFROM field in this table indicates another product, if any, from which this record represents 
a sub-product or sub-component. Such linking of products permits recursive definition of the 
products to provide a richer definition of products and related sub-products. For example, 
"TABLE SAW" may be the name of a product and "SAW BLADE" may be the name of a related 
sub-product.," Kark, Para. [0085], emphasis added.) One of ordinary skill in the art would 
understand that the LINKFROM field of Kark is used to link together a group of products that 
roll up to a single parent product and therefore does not teach or suggest "mapping said 
description of said provider offering with said resource type information . . .comprising the steps 
of: . . . adding child nodes to said identified nodes when said identified resource types , which are 
aggregated resource types, map into a set of lower level resource types which are child 
resources " as recited inter alia in Claim 15. ("The LINKFROM field of a highest level product 
(one which is not a sub-product of another product) indicates the CATEGORYID value of the 
category, if any, to which it is linked, or, if not included in a category, the LINKFROM field for 
such a product indicates a NULL or other invalid value to so indicate a top level product ," Kark, 
Para. [0085], emphasis added.) 

In addition, with regard to Claim 1 5, the Examiner alleges that Kark teaches "compiling 
said sequenced management actions into a machine readable form executable by said resource 
management system." The Examiner alleges that Kark teaches "the process may also be 
performed automatically using time event processing and script controls." The Examiner alleges 
that, because Kark discloses scripting, and that scripting maybe considered computer executable 
programming, Kark by extension teaches "compiling said sequenced management actions into a 
machine readable form executable by said resource management system," as recited inter alia in 
Claim 15. ("scripting is an old and well known synonym for computer executable programming. 
The scripting of Kakr inherently is contained on a computer readable medium. Therefore the 
teachings of Kark would have rendered the claimed limitations obvious to one of ordinary skill in 
the art at the time the invention was made," the Examiner's Answer, pg. 22.) The Examiner 
additionally appears to interpret the aggregation of catalog data into a single master catalog as 
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"compiling." The Examiner therefore apparently concludes, that because Kark allegedly teaches 
that the aggregation of a master catalog can be performed using a script, that Kark must teach or 
suggest "compiling said sequenced management actions into a machine readable form executable 
by said resource management system," as recited inter alia in Claim 15. The Appellant 
respectfully disagrees. Kark discloses that manual process may be automated using scripting, 
however, Kark does not disclose "compiling said sequenced management actions into a machine 
readable form executable by said resource management system," as recited inter alia in Claim 15. 
Claim 15 recites inter alia " providing access to a resource management action catalog containing 
resource management actions each describing how to manage a single resource type by a resource 
control system. . . extracting from said resource management action catalog all resource 
management actions of said resource types identified in said customer specific service 
environment resource topology tree; sequencing said extracted resource management actions 
according to requirements of said defined customer specific service environment; and compiling 
said sequenced management actions into a machine readable form executa b le by said re s o urce 
management system .'" The scripting of Kark, therefore, does not teach or suggest "compiling said 
sequenced management actions into a machine readable form executable by said resource 
management system," but discloses a way to automate catalog aggregation, ("an integrator or 
integration means that integrates updated information from a parent catalog into a child 
catalog . . .This particular integration is performed under the manual control of a user. As noted 
above, the process may also be performed automatically using timed event processing and 
scripting controls as well-known in present computing systems," Kakr, Para. [0113], emphasis 
added.) 

Yanagimachi does not correct the deficiencies identified with Kark. Therefore, for at least 
these reasons, Claim 15 is allowable over Kark in view of Yanagimachi. The Appellant 
respectfully requests reconsideration and withdrawal of the rejection of Claim 15. 
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CONCLUSION 



In view of the foregoing, it is urged that the rejection of claims 1-15 be overturned. The 
rejection is in error and should be reversed. The fee set forth in 37 CFR 41 .20(b)(2) is enclosed 
herewith. If there are any additional charges with respect to this Reply Brief, or otherwise, please 
charge them to Deposit Account No. 09-0463. 

Respectfully Submitted, 

CANTOR COLBURN LLP 

By /Nelson S. DaCunha/ 
Nelson S. DaCunha 

Date: October 4, 2011 Registration No. 63,592 

20 Church Street, 22 nd Floor 
Hartford, CT 06103-3207 
Telephone: (860) 286-2929 
Facsimile: (860) 286-0115 
Customer No. 46429 
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